APPENDIX A -TABLES 



Task ID 


Ti 


Cb,i 




6 


1 


X2 


7 


1 


T 3 


21 


2 



Table (1) - Periodic Task Set 



Notation 



Description 



r, The task in a process with priority level t. In traditional RMA, r, is a single thread and 

the whole system is a single partition. In DEOS, we call ry an aggregate thread. There 
are many threads running at the same rate in DEOS. So, if ti,i,t,',2,...,tt,nj are all the 
threads defined for rate \ } n is the sequence of these threads when run back-to-back. This 
representation allows us to consider slack only in terms of rates and not in terms of threads 
which potentially helps performance significantly. 
n The number of distinct (aggregate) threads allowed in the system. This number is fixed 

at system power up. 

Ti The time between dispatches of r». We assume without loss of generality that 

Ti < T 2 < ... < T n . Ti is also called the period of ry. In DEOS, strict inequal- 
ity holds. 

H The hyperperiod of the task set. H = lcm(7i,72»...Tn). Note that in a harmonic system 

such as DEOS, H = T n . 

The j th dispatch of r,-. Again, in DEOS, nj is an aggregate thread. 



The worst case execution time for r tJ . In classical RMS the task set is fixed so C»> = C,* for 
each dispatch j where j = 1, .., Note that this quantity is computed at each successful 
schedulability test. 

A short hand notation for dj when C»j ',== C\k for all j, h € {!)«■■, " 



Table (2) - Periodic Thread Specification in Classical RMS 



Notation 


Description 


n./i 

Ei 

Aperiodic* 

n 


The value ^ for t > j. n,/j is the number of times r, will execute during one period 
defined by T%, For a harmonic system, all n,*/, are integers. 

The level t slack in the interval [0,; • T,] assuming all' periodic processes take their worst 
case execution time to complete. 

The dispatch identifier of the next instance of r; to complete. If r, is in state Completed- 
ForltsPeriod, this is the next instance, otherwise it is the current instance. This value must 
be maintained at runtime. When aggregate threads are supported, one state variable per 
thread may be necessary. 

The amount of level t or higher aperiodic time that has been consumed since the beginning 
of the hyperperiod. This includes all time consumed by aperiodic task of priority 1, ...,t, 
where periodic process overrun can be considered aperiodic process computation time. 
There is an implicit time argument, so Af>€rlodUoTifne-* L - /^eri€AicTtrtVe{Ct'). 
level i idle time that has occurred since the beginning of the hyperperiod. This is all the 
time not speiitr processing tasks of priority i or higher. In other words, it is all the time 
sperilT processing tasks (periodic, aperiodic qr;/idle) of priority t + 1, n + 1 where n is 
the number of rates in the system, arid level n + 1 is the idle process. There is an implicit 
time argument, so T^l^ = XcA^^vt )• 

The dispatch identifier of r,, or equivalently the period identifier of Ti. There is an implicit 
time argument, so -y,(t) = 7;. 

The amount of level i — 1 slack available in [0,j • Ti] which is the amount of time available 
for processing tasks at level i — 1 without causing rj, r?, r; to miss any of their deadlines 
in that interval. 



Table (3) - Slack Scheduling Specification in the Context of Classical RMS 



Dispatch ID 


1 


2 


3 


4 


5 


6 


7 


Timeline 


5 


10 


15 


20 


25 


30 


35 


Slack y 


4 


9 


14 


19 


24 


29 






12 


25 













Table (4) - Timeline Slack ij 



Dispatch ID 


1 


2 


3 


4 


5 


6 


TimelineSlack(l,30) 


4 


8 


12 


16 


20 


24 


TimelineSlack(2,30) 


6 


12 


18 








TimelineSlack(3,30) 


10 













Table (5) - TimelineSlacky 



-Thread Servics 



Description 



;createThread 
JtartThread 

StartTh reads 



•festartThread 
killThread 

fitopThread 
HtaitUntilNextPeriod 



4estartProcess 

createMutex 

lockMutex 

unlockMutex 

resetMutex 

waitForEvent 
pulseEvent 



Creates a new thread. If the thread is dynamic, it also starts the thread. 

Schedules to have the (static) thread started at the beginning of the next period defined 
by the threads rate, after the start service has completed. 

Schedules to have the set of threads started at the beginning of each of their respective 
periods defined by their rates, after the start threads service has completed. 

An active thread is restarted from the beginning. 

An active dynamic thread is deactivated. A stopped static thread is also deactivated. 

This routine is newly added. Static threads must first be stopped before they can be killed. 
The calling thread is suspended until the start of its next period where it resumes execution. 
Other threads queued at a mutex that the calling thread holds will be dequeued. 

All the process* threads, mutexes and events are killed. The process' primary thread is 
restarted. 

Creates a mutex that can be accessed by multiple threads in the calling thread's process. 

The calling thread is granted the lock if the mutex is unlocked and queues if waitlok is sc 
true. 

A thread releases its lock on a mutex and the lock is granted to the highest priority thread 
(if any) waiting. 

All threads queued at the mutex are dequeued (including an executing thread). 
The calling thread is suspended until the event is pulsed. 

All threads currently, waiting for the pulsed event will transition from state suspended to 
state ready. 



Table (6) - Thread Services 



# 



Notation 


Description 


Ti 

n 

Uj 
Ti 

7i 

mi(t) 

m{ 
Ci 

Ck 

z 
C 


The aggregate of threads with priority level i. We call r, an aggregate thread. 

The number of distinct rates allowed in the system. This number is fixed between 

coldstarts. 

The j th thread of priority level t. Even "though there is no explicit ordering of threads 

within a priority level, it is convenient to do so for the sake of reference. 

The time between dispatches of r,. We assume without loss of generality that 

Ti < r 2 < ... < r«. 

The period identifier. At time t where t G [0, H] t ji(t) = 7, = f 

The number of active threads forming r, at time t. For ease of exposition, the t is often 
omitted and refers to the current period of Ti so m,*(<) = mi. Note that there is a time 
lag between thread creation and thread activation. 

A temporary value for m; when threads will but have not yet become (de) activated. 
The worst case budget times summed over all threads forming r,\ 

The value |£ for i > j. n,^ is the number of times r, will execute during one period 
defined by Ti. 

The primary budget of process Jb, Jb g {1, ...,?}, j> = number of active processes. Note that 
a process can be active and have its primary thread stopped, in which case some portion 
of its budget is available as timeline slack. This is poor notation actually since the set of 
active processes changes. 

The set of all processes whose unallocated primary budgets are available for slack. 
The sum of the Cfc budgets available for slack. C = J2k&z £ fc * 

System level utilization reserved for blocking times. A feasibility test is always of the form 
U < 1 - U B * 



Table (7) - Periodic Thread Notation 



[ Notation 


Description | 


a. (<a$o 

A 

Aperiodic 
Time^t) 

Idlest) 


is the amount of timeline slack that was made available from processes with inactive 
primary thread budgets with rate t at time ji(t)Ti. Note: Ai is not cumulative since the 
beginning of the hyperpeiiod. Also, in the current release of DEOS, it is always true that 
Ay = 0for>€{2,...,n}. 

The vector (Ai, A2, A„) which is maintained at run-time. 

The amount to change rate A,- the^next iime the start of periods denned by Tj and T» 
coincide. It will be the case that ford-> j, AAij = 0. Values of AA» ; - are updated to 
reflect user thread (de) activation requests at level » with an inactive primary thread at 
level j. Note also that if there are no primary threads active at rate t, then AA*> = OVj. 
The number of threads in aggregate thread n for * = 1, ...,n. m, = n»i(t). 
The k th thread in r<, for k = 1, ...,m,. 
The budget of Uk- Set when Uk is created. 

The actual execution time of Uk for the current dispatch. If the current dispatch has 
completed then it is the total time that dispatch oft,* took to execute. 0 < < 
A boolean value indicating r.-'s activation status. If r» is active, Ei = TRUE otherwise Ei — 
FALSE. This value is maintained at runtime. 

the amount of level t aperiodic time consumed in [7»(t)T,, t]. For simplicity, we denote 
AperiodicTimei(t) =. AperiodicTimei. 

the amount of "level" t idle time (i.e. time .spent, running the idle process) in [7i(*)T»>*] 
no longer available to slack. For simplicity we denote 3*Mej("0 — Xdf^^* 
a conservative estimate of the amount of level i idle time that is lost as level t reclaimed 
slack due to sitting idle. 

The amount of slack reclaimed by completing for period at level t in [7»(*)2i>*]- 

The period identifier for Ti. For i G *1,2, ...,n},7,(t) = [^J. Alternatively, one can think 

of ji as the dispatch identifier for r,-, 7, € {0, 1, ...,H/Ti — 1}. 

A conservative value of the amount of level k slack available that can be carried over to the next 
period T k . 


CurlD(i) 
USys 

AUSys(l.-n) 


This is associated with the system, and uniquely identifies the period T». Comparisons of 
the form P.ReqlD(t) < CurlD(i) will appear in the algorithms. Sometimes these will be 
abbreviated P.~fi < 7,-, where uniqueness is understood. See comments in the text about 
counter roll over. 

System utilization allocated to active processes, including pending requests for cre- 
ation/activation and deletion /deactivation. Note that USys does not necessarily reflect 
the current utilization allocated to active processes. 

Changes to the actual process utilization allocated to active processes that will take place 
at the next period boundary of Ti, at level ». 


*;« 


The remainder of full Tj periods remaining in the current (relative to t) Ti period. In 
symbols, n* {i (t) = L(( 7 ;(*) + W - W^J.- 

The remainder of any unused fixed budgets belonging to ISR threads at rates 1 in 
the interval [<, (7>(*) + 1)2}]. 

The sum total of all fixed budgets belonging to ISR threads at rates in any Tj 
period. In this release of DEOS, if B{t) is the worst case "aggregate" ISR fixed thread 
budget (at time t, since ISR threads can be killed/created), Bj(t) = n > | 1 B(<) > a quantity 
that should be easy to maintain at runtime. 



Table (8) - Slack Scheduling Notation 




Notation 


Description; 


UserBudget 

MaxBudget 
Rate 

Active " 

Pr cActive 
ReqlD(i) 

7* 

ABudgetReq(t) 


The total amount of time (normalized by the process* primary thread's period) allo- 
cated to active users within the process. UserBudget will never exceed MaxBudget, which 
is the process' entire budget. UserBudget reflects any pending changes indie tated by 
ABudgetReq. Consequently, UserBudget is not necessarily the current value of the pro- 
cess 9 budget assigned to user thread. But that value can be computed. 
The process 1 total budget, normalized by the period of its primary thread. The term 
budget is somewhat misleading. Utilization is a more descriptive term. 
The rate at which the highest priority thread (including the process' primary thread) runs. 
Note that no user thread of a process p will have a rate higher than the process' primary 
thread. It is TBD whether there is benefit in having a primary thread with rate higher 
than any of its users. Rate takes on one of the values l,...,n, with 1 the highest rate, and 
n the slowest rate. 

A boolean value set to TRUE when the" primary thread is active and false when the primary 
thread is inactive. When p.Active is FALSE, the primary thread's budget is made available 
as timeline slack. 

A boolean value set to TRUE when the process (not just its primary thread) is active, 
otherwise it is FALSE. -» P.Proc Active => -» P. Active (regardless of its value). 
This uniquely represents the most recent time a request for user thread (de)activation has 
been made at level t . Note: it is not sufficient to use 7, since these table values are not 
updated "periodically", but only when other (de)activations take place after the requests 
have been processed. 

We sometimes denote P.ReqlD(i) by P. 7; where it is understood that P. 7, uniquely defines 
the request period T; . 

This is the amount of change in allocated budget at level • that either will or did occur 
at time (ReqlD.-(t) + 1)7*. If the change hasn't yet occurred, subsequent requests niight 
change this value. 



j\ Table (9) - Process Record Attributes (Budget Update Vector) 





Notation | 


Description 




ComputeTime 


The total compute time allocated to the thread. A timeout will be enforced to ensure that 






a thread does not exceed its worst case compute time. 




CT 


An abbreviation for ComputeTime. 




ExecTime 


The total time spent executing so far. This time is updated at each thread preemption or 






suspension. 




ET 


An abbreviation for ExecTime. 




TimeSlice 


The amount of time a thread is allowed to execute prior to a hardware timeout. Ex- 






amples of timeouts are maximum xnutex execution times and maximum available slack 






consumption before thread suspension. 




TS 


An abbreviation for TimeSlice. 




Ei 


A boolean, denoted by Ei for aggregate thread n which is true if all threads at rate i have 






a true value for CompletedForltsPeriod and false otherwise. 




Execu ti ngO n S I ack 


A boolean value which is true when a thread's budget current budget has been from taken 






from the slack pool and false when it is a part of its fixed budget. 



Table (10) - 



Thread State Time Variables 



Notation 


Description 


Slack 


A record perhaps indexed by slack level (depending on the slack consumption algorithms) 
con* ami « g me amount 01 siacK, reciaimea. ax level i 9 ana tne most recent period j.% aunng 
which it was reclaimed. 


Slack.?; 
Slack.7t,- 


The identifier of the most recent T% ^period daring which level i slack was consumed, 
f E {0, ... 9 H/Ti — 1}. This attribute is not used in the maximal update set of algorithms. 
The amount of slack reclaimed by completing (early) for period at level i within the 
"current" period defined by 7,. Slack.Tlj is set to zero at every period boundary defined 
by Ti. 

An abbreviation for Slack. 7£», which works only when the slack record is not indexed. 
The amount of unused slack at level t that has been carried forward at time 7;(i)T;. 
Slack. Ui is recalculated at every period boundary defined by Ti. 

An abbreviation for Slack- Ui, which again works only when the slack record is not indexed. 


Hi 

Slacks 

Ui 


Slack(j) 


The slack record associated with a slack consuming thread (if any) at level j. In this 
situation, slack made available at the higher rates is allocated directly to high rate slack 
consumers, without taking away (or recalculating) slack previously allocated to low rate 
slack consumers. This record is not used in tKe maximal update set of algorithms. 



Table (11) - Slack Record Attributes 



APPENDIX B - ALGORITHMS 



— Algorithm UpdateldleSIackVariables(t: in priority); 

This algorithm updates the idle slack variables used when computing slack availability. 

It is called whenever a periodic task completes. 

— — update-time = the worst case time to execute this routine, a constant (perhaps based on t). 

E% := (Ei + ljmod^c; - update the activation status 
idlejtimexonsumed := execution-time(ri); 

slack-reclaimed := worst jcase_execution_time(r,) - idle -time -consumed; 
for j := 1,...,* — 1 loop 

Ij := Ij + idle-consumed + update-time; 
end loop; 

for j := l,.. M n loop 

Tj := Ij - slackjreclaimed -f updateJtime; 
end loop; 



Algorithm (1) - Update Idle Slack Variables 



— Algorithm UpdateAperiodicSlackVariables(t; in priori ty t t : slack consuming thread); 

This algorithm updates the aperiodic slack variables used when computing slack availability. 

It is called whenever an aperiodic task completes, which might include surplus compute time for a periodic 

— task increment, or the idle task completing. 

updateJtime = the worst case time to execute this routine, a constant (perhaps dependent on t). 



the aperiodic task t may execute over several time increments, i.e. it may be sche< 

— consume all slack, suspend itself, be rescheduled when more slack is available, etc. 
slackxonsumed := execution-time-sinceJast-scheduling(t); 
for j ;= - 1 loop 

Ij ;= Ij + slack-consumed 4- updateJtime; 
end loop; 

for j := t, ...,u loop 

Ij := Ij -f updateJtime; 

Aj := Aj + slackxonsumed; 
end loop; 



Algorithm (2) - Update Aperiodic Slack Variables 



# 

- Function AvailableSlack(i: in priority) return time; 

- This algorithm calculates the slack available beginning at the time of the call and ending at the 

- end of the period defined by T% % assuming no new threads were created and no existing threads are destroyed. ' 

slackjcalc-time := the worst case time to execute this procedure (perhaps based on t). 
for j := 1, ... t t — 1 loop 

Tj izz Jy-f slack jcalclime; 
end loop; 

for j :=i,.. M n loop A 
Tj :ss slack-calcthne; 
* ^ : =A J(jEi -(^ i +J ; ); 
end loop; 

slack-available := min 1<J<n Sj\ 
return slacks vailable; 

in practice, return zero if slack-available < cswap time +5; y 

updateAperiodicSlack Variables should be called prior to execution of this routine, if necessary. 



Algorithm (3) - Available Slack 



Indefinite Timeout Protocol(c : caller; r : resource); 

if not^available(r) then 
if c. has -successors 

then estate := CompleteForPeriod; 

rjella^ ) ; 

dequeue(c,queue(r)); 
else 

if eExecutingOnSlack then c.budget -remaining := availablcslack(crate); end if; 
if c. budget-remaining < queue jtime(c) 

then estate := CompletedForPeriod; 

slack reclamation may not be worth it here; 

else 

enqueue(c,queue(r)); , 
if c, Slack and SlackOn 

then ^ - eresource.time(r)); 

estate := PassivelyWaitingForEvent; 
r^redecrement sl^ accumulators by c. resource _time(r) ; 
else 

estate := ActiveiyWaitingForEvent; 

— This type of wait introduces effective blocking. 

end if; 
end if; 
end if; 
else 

if c.ExecutingOnSlack then ebudget remaining := available jslack(erate); end if; 
if ebudget remaining < resource-time(r) 
then estate := CompletedForPeriod; 

release(r); dequeue(c,queue(r)); 
else continue the execution of c with resource r available; 

Slack acciimulators need to predecremented if c is executing on slack and r is a mutex. 

end if; 
end if; 



Algorithm (4) - Indefinite Timeout Protocol for a Resource Wait 



# 



Long Duration Timeout Protocol(c : caller; r : resource; numJter : natural); 

if no t -available (r) then 
if num Jter = maxJter 

then dequeue (c t queue(r); return; 

else numJter := numJter + 1; 
end if; 

if chas-successors 

then estate := CompleteForPeriod; 
gjrec^^ udge t ) ; 

Sequeue(c,f); - At the next start of c's next period* c will he moved to r's queue by DEOS 
else 

if^^ecutingOnSlack then c.budget -remaining := available_slack( crate); end if; 
if c. budget .remaining < queue -time (c) 

then estate := Completed For Period; 

sla^^reHamatibn riot be worth it here 

else 

enqueue(c,queue(r ) ) ; 
if ^Slack aiid SlackOn 

then.redaim^lackferemainmgPixedBudget - c.resource-time(r)); 
estate := PassivelyWaitingForEvent; 
predecrement slack accumulators by c. resource-time (r); 
else 

estate := ActivelyWaitingForEvent; 

— This type of wait introduces effective blocking. 

end if; 
end if; 
end if; 
else 

if c.ExecutingOnSlack then ebudget remaining :- available jslack(erate); end if; 
if ebudget .remaining < resourceJime(r) 
then estate := CompletedForPeriod; 

release (r); dequeue ( c, queue (r)); 
else continue the execution of c with resource r available; 

— ^Slack^.CTmiulat c is executing on slack and r is a mutex. 

end if; 

end if; ; 



Algorithm (5) - Long Duration Timeout Protocol for a Resource Wait 



Short Duration Timeout Protocol(c : caller; r : resource); 

while c.priority <= ready Jthread. (inherited) priority 

wait; higher or equal priority threads are running 

end while; 

— — c is at the head of queue(r) 
if not_available(r) 
then 

return timeout status to c; dequeue(c ( queue(r)); 
estate := CompletedForPeriod; 
else 

case r.type is 

when r = event => continue the execution of c with event r pulsed; 
when r = mutex grant c the lock to mutex r; 

— when c is executing on slack ,^^^i^iernentvthe slack accumulators 
when r = semaphore => c calls wait(r); 
end case; 
end if; 



Algorithm (6) - Short Duration Timeout Protocol for a Resource Wait 

- Algorithm SystemlnitializationOfSlackVariables; 

- This algorithm is called once before the start of the initial hyperperiod. 

— Failure to initialize slack variables at this time will result in bogus values later. 

— This algorithm requires modifications when primary thread periods can be other than T\ . 

Z:=0; 

C:=0; Co:=0; 

for each process P in the registry loop 
calculate/read P's budget, ( p \ 

P.UserBudget := 0; P.MaxBudget := ( p ; P.Rate 1; 
* P.ReqID := (0,0, ...,0); P.ABudgetReq := (0,0, ...,0); -™ Vectors of n zeroes. 

Most likey, if P.Proc Active, then P. Active will be assumed at system startup? 

if P.ProcActive then 

if P. Active then — P's primary .thread is active 

then (q ;= Co + ( P \ 
else<:=C+<p;2:=^U{P}; 
end if; 
end if; 
end loop; 

for t := 1, ,..,n loop 

Ti := the period of the i th smallest rate declared in the system; 
Ai := 0;Ci := execution time of t;; 
AUsys(i) := 0; 
for j 1, ... t i loop 

n <U := T^T,; AA; tJ := 0; ' V 

— (njjj), (AAij) are diagonal matrices, 
end loop; 
end loop; 

Ai :=T!-(C + Co + t/B); 

Ai := system level slack = budget not assigned to active processes minus system blocking time: 

USvs:=« + Co)/T i; 



Algorithm (7) - System Initialization of Slack Variables 





Algorithm PeriodUpdateOf Slack Variables (j : in rate); 

This algorithm is called at the start of every period. That is at times 0, T>, 2Tj ... 

This algorithm is called once at the largest period. That is, the start of a period for Tj 
is also the start of a period for T k when k < j. 

r indexes the rates at which primary periods are supported. 1 . 
In the current release of DEOS, r = 1, always, so this is an O(n) routine. ' 

When thread (de) activations occured, update changes in dynamic period timeline si 

Ohe may have to introduce process sets with indices for their primary threads. 

Z:=Z'; Z':=Z; 
for k := l„j loop 

U k is a conservative amount of level k slack available and not used in the last T k per 
Not all of 7l k can be attributed to U k but can safely be assigned to U n - 
U k ;= U k + max(0 t (A* - {Ak + 
U n :=U n + 7l k ; 

I k := 0; A k := 0; H k := 0; C k := 0; 
E k := FALSE; *y fc := 7* + 1; 
AUsys(ik) := 0; 
a := 0; 

In this release of DEOS, the loop here is simply A k := A k + X^r=l & A i r ' 

— and then zero out the A^4i r entries, 
for r := Jk..j loop 

a := <r 4- AAjkrl 

AA fcr :=s 0; 
end loop; 
A fc := Ajt + <r\ 



end loop; 



if j ss n then 

for k := l..n loop 



we are at the hyperperiod, reset the period id's and unconsumed slack. 



Tic — 0; 
U k := 0; 
end loop; 



end if; 



Algorithm (8)- 



Period Update of Slack Variables 



« * 



Algorithm PrimaryThread(De)activation(P : process); 

If P.active, then deactivate P's primary thread else activate P's primary thread. 

(De)activation request "processing" time is at s, where 7 r T r < s < (y r + l)T r , with r = P.rate. 



— — Notation used defined below and is the same as that above. 

n y|r = TV/TV. 
r P.rate; 

There may be some pending requests for activations/deactivations that will not be in effect at time (-y r (s) + l)T r . 

for j := r..n loop 

if RABudgetReq(j) > 0 and then CurID(j) > P.ReqlDQ) then 

These updates have already occurred. Zero them out. 

RABudgetReq(j) := 0; RReqID(j) := 0; 
end if; 

if (CurID(j) = P.ReqID(j) and (( 7 j + l)Tj > {y r + l)T r )) then 

P.UserBudget := RUserBudget - ABudgetReq(j)/nj| r ; 

ABudgetReq(j) is left unchanged for later updates. 

end if; 

if P.Active then 

AArr := AArr- (P.MaxBudget - P.UserBudget)T r ; 
else; 

AArr AA rr -h (P.MaxBudget - P.UserBudget)T r ; 
end if; 
end loop; 

if R Active then R Active := FALSE else P.Active ;= TRUE; end if; 



Algorithm (9) - Updates for Primary Thread (De)Activation Requests 



+ 



Algorithm UserThread(De)Activation(£: time; j rate; P: pro'cess; activation : boolean); 

P is the process of the thread being (de)activated. 

j is the rate of the thread for which (de) activation is being requested. 

S is +/— the budget of the thread (in time, not utilization) requesting de/activation. 

I.e. S < 0 the call is for a deactivation request, and S > 0 the call is for an activation request. 

activation is a boolean, which is actually redundant information given S*a sign. 

Can we admit a new thread at level j? 

(De)activation request time is at s, where IjTj <s< (ltj + 

This assumes that deactivations have at most a one period delay, which is coming soon. 

The execution of this code is at time s, with period boundary code executed at time ('yj + l)Tj. 



Notation used defined below. 

n j\h ^Tj/Th- 

r := P.rate; P's primary thread's rate. 

CurlD(j) is similar to yj t except it must uniquely identify which period Tj we are in since 

P.CurlD might not have been updated for many hyperperiods, hours, or since system boot. 

for i := 1, .., n loop 

if P.ABudgetReq(j) ^ 0 then 

if CurlD(t) > P.ReqlD(i) or P.ReqlD(i) - CurlD(i) > n n(1 then 
P.ReqlD(t) 0; P.ABudgetReq(i) := 0; 

These updates have already been made. Zero them out. 

end if; 
end if; 
end loop; 

If an activation check for feasibility, and if feasible readjust the compute times within the process. 

if activate then 

UserBudget := P. UserBudget; 

for t j -f l..n loop 

UserBudget := UserBudget - min(0,P.ABudgetReq(i)); 

end loop; 

if UserBudget +6/Tj > P.MaxBudget 
then 

reject the activation request on the grounds of infeasibility; 
return; 
end if; 
end if; 

P.UserBudget := P.UserBudget + S/Tj; 

P.ReqID(») := P.CurlD(t); P. ABudgetReq := P ABudgetReq + S/Tj; 
if not P.Active then 

AA rj := AA r j + S/n J | r ; 

Here is where we would update AC rj if aggregate threads are used. 

-end if; 



Algorithm (10)- 



Updates for User Thread (De)Activation Requests 



* * 

— Algorithm Process(De)activation(P : process, r : rate; activate : boolean); 

This request is made at time i. If granted, it will become effective at time (7r(0 + l)T r where r := P.Rate; 

C P := the worst case compute time of P measured every T r time units. (This would be input in a create,) 
if activate 
then 

if P.ProcActive then return either an with error or as a no-op; end if; P is already active. 

Determine whether activating P will result in a feasible- process, set. 

SysBud := SysU; 

for t := r + 1, n loop 

SysBud := SysBud - min(O f ASys(i)); 
end loop; 

if SysBud +<p/?V > 1 - U B then 

reject activation request; return; infeasible 

end if; 

Activation is feasible 

P.Rate := r; P.Active ;= TRUE; P.ProcActive := TRUE; 
RMaxBudget := fa P.UserBudget := 0; 
PrimaryThread Ac t iva tion( P) ; 
ASys(r) := ASys(r) + ( P /T r ; 
else a deactivation request which have no feasibility test 

if P.UserBudget ^ 0 then return error; end if; 
PHmaryThreadDeactivation(P); 
P.ProcActive := FALSE; 
ASys(r) := ASys(r) - < P /T r ; 
end if-then-else; 

This is another place where the AC matrix is updated, and also Z* . 

Tte* (flCtfCT W(*f ttft b£|fc6atalwhen all processes are assumed to be declared statically. 



Algorithm (1 1) - Process (Deactivation 



Algorithm UpdateRedaimedSlack(i: in priority); 

This algorithm updates the reclaimed slack variables used when computing slack availability. 

It is called whenever a task executing on fixed budget completes for period: 

The same algorithm applies whether doing incremental or aggregate updates. 



if r t has completed then 

slack-reclaimed := ComputeTime(Tj)— ExecTime(r ( ) - updateJime; 

update-time is the time to execute this code 

7li ;= 7c t -+ max(0,slack-reclaimed- £,); 
end if; 



Algorithm (12) - Update Reclaimed Slack Variables 



Algorithm UpdateldleSlackVariables; 

This algorithm updates the idle slack variables used when transitioning from busy to idle, 

It is called whenever when the idle task completes (at priority (n+ 1)). 

I.e. the idle process is denoted by r n +i . 

updatejtime =: the worst case time to erecute this routine. 

idle-time := ExecTime(r n +i); 

The assumption for DEOS is that idleJtime < Ti. 

To relax that assumption would require more bookkeeping. 

i := is 

while idle .time > 0 and j < n loop , . . m ^ x / ^ _ » 

— s|*ck-o^l«|> |e. ;=t (At +-OJ -h Rj) - {Aj + Xj) 

if idleJtime < slack_available then ^ *J \J 

Xj := Xj+ idleJtime; idleJtime := 0; 
end if; 

Cj is denned as the worst case compute time, but can be reduced 

to the worst case amount of time threads at level j can wait for a resource 

and not give up their time to the slack. 

In DEOS, as I understand it, this is only ISR threads which run at rate 1 . 

I believe the algorithm works for threads that can wait for resources while holding budgets. 

I also think under these conditions, it is suboptimal. 

if slack-available < idleJtime and idleJtime < (Aj ; + U : + Cj) then 

Xj := Tj-f slack-available; 

Cj := £j+ (idleJtime - slack-available); 

idle-time := 0; 
end if; 

if idleJtime > (Aj + Uj + Cj) then 
Xj := Xj + slack-available; 
Cj := Cj + (Aj + Uj + Cj)- slack-available; 
idleJtime := idleJtime - (Aj + Uj -f Cj)\ 
end if; 
end loop; 



Algorithm (13) - Update Idle Slack Variables 

Algorithm Update AperiodicSlack Variables (i: in priority, i : slack consuming thread); 

This algorithm updates the aperiodic slack variables used when computing flack availability. 

It is called whenever an aperiodic task completes, which might include surplus compute time for a periodic 

task increment, or the idle task completing. 

update-time = the worst case time to execute this routine, a constant (perhaps dependent on t). 

the aperiodic task t may execute over several time increments* i.e. it may be scheduled, 

consume all slack, suspend itself, be rescheduled when more slack is available, etc. 

slack .consume d := executionjtime-sinceJast .scheduling (t) *f up date -time; 
i := i ; 

while slackjconsumed > 0 loop 

Ijs := min(slackxonsumed, max((Aj 4* Uj + Uj) - (Xj + slackxonsumed),0)); 
slackjconsumed := slackjconsumed — ljs; 
Aj :=Aj + Us; 

i:=i + i; 

end while; 



Algorithm (14)- Update Aperiodic Slack Variables 



— Function AvailableSIack return an n- vector of slack time = (5(1), 5(2), ...,S(n)); 

— This algorithm calculates the slack available beginning at the time of the call, say a and ending at the 

— ends of periods denned by ((71 (s) + l)Ti , (72(5) + l)T 2 , .... (-y n (*) + l)T„). 

— Note that more period timeline slack may become available in these intervals after this request. 

— This differs significantly from the original slack stealer. 

— Note the difference in fonts for A t - and -4, . They are different variables. 

slackxalctime := the worst case time to execute this procedure; 

for j :== l..n loop 

S := (Aj + 7lj + Uj)~ (Aj + J/+ slack jsalcaime); 
Su := Su + S\ 

if Su < 2(cswap + 6) ■+ cachebonus 

then Sj := 0; 

else Sj := Su ; 
end if; 
end loop; 

return S = (Si ,«S 2 , 

in practice, if the slack available at any level is too small to cover the cost of context swaps 

plus other overhead, using it causes a negative effect. ~ ^ 
8 and cacheBonus is selected based on system overheads beyond cswaps. 

Update AperiodicSlack Variables should be called prior to execution of this routine, when necessary. 

UpdateldleSlack Variables will have automatically be called prior to exaction of this routine. ' 



Algorithm (15) - Available Slack 



